Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Design and Tuning Hints

The replicated system tends to have the characteristics of the type of application it is running. It is rarely necessary to make major design changes solely for the replication features. However, you should keep the standard design goals in mind and make sure that networking and CPU usage is considered. In designing this system, use the following goals to achieve optimal performance:

  Isolate sequential I/Os. Most of the time spent reading from or writing to the disk is spent seeking to where the data is located. If you can reduce seeks, you can achieve more I/Os per second.
  Spread out random I/Os. Random I/Os have a maximum rate per drive. By spreading the I/Os out across many drives, you increase the overall rate.
  Avoid paging and swapping. Any time the system pages or swaps, performance is severely degraded. Avoid this at all costs.
  Avoid saturating the network. Because replication data is transmitted over the network, make sure that you have sufficient bandwidth.
  Have sufficient CPU and I/O capacity. Because the replication functions add overhead to the system, make sure that you have enough spare CPU horsepower and I/O bandwidth to accommodate this addition.

The optimal layout of the system is based on the application type. If you are performing OLTP functions, use a design that provides optimal OLTP performance. If you are performing DSS functions, optimize for DSS. Keep in mind that even with DSS-type applications, you will have significant update activity from the replication itself. These factors all contribute to the optimal data layout of your system.

Design

The main goals in designing the physical data layout are to provide balanced I/Os across all the disks that are randomly accessed and to isolate the sequential I/Os. Base the design of your system on the type of application you are running and factor in the additional update activity of the replication function. In a DSS-type system, remember to isolate the redo log files and archive log files because there is significant update activity from the replication functions.

A minimal configuration should look something like this:


Element (# of Disks) Comments

System (1+) The system disk is used for the operating system, swap file (if applicable), user files, and Oracle binaries. If possible, mirror this disk for additional fault tolerance.
Redo log (1+) You should have at least one log volume. This volume should be made up of at least two physical disks using RAID-1. By using only one log volume, performance is degraded during archiving because the sequential nature of the log writes is disrupted.
Archive logs (1+) The number of disks needed for the archive log files is determined by the amount of data you need to archive. This data can be written to tape as necessary.
Data and index (1+) Because you always get concurrent access to disks with a disk array, it is not necessary to split the data and indexes into separate volumes. The number of disks you need for data and index is determined by the amount of random I/O your user community generates.

Although these recommendations are based on the use of a disk array, traditional Oracle striping across individual disks also works. Both the data files and the indexes should be striped over as many disk drives as necessary to achieve optimal I/O rates on those disks.

As you can see, the design of a replicated system is similar to those of other systems. The only difference in the design is providing for the additional network, CPU, and I/O load generated by the replication function.

Tuning

The type of tuning needed for a replicated system is determined by the type of applications to be run on the system. Rather than re-hash all the tuning parameters you should consider, the following list touches on parameters of interest to the replication function itself.

For the replication function, monitor the following parameters to verify that you are not running out of resources:

  DB_BLOCK_BUFFERS. Because there is additional update activity caused by the replication function, make sure that you have a sufficient number of block buffers.
  Library cache. Check the V$LIBRARYCACHE table, which contains statistics on how well you are using the library cache. If necessary, increase the value of SHARED_POOL_SIZE.
  Data dictionary cache. Make sure that the data dictionary cache is of a sufficient size.
  Rollback contention. Because the replication updates are done in batch jobs, you may have to add some large rollback segments or increase the number of rollback segments in the system.
  Latch contention. Monitor the latch contention in your system and take action if latch contention is an issue. Chapter 9, “Oracle Instance Tuning,” describes how to determine whether there is a problem and how to correct it.

Use this checklist in addition to whatever tuning checklist you have compiled for the main function of your system. This list is concerned only with the replication facility.

Review of the Replicated System

The replicated system is configured and tuned based on the type of application it is running. The exceptions to this are in the following areas:

  CPU usage. The system may require additional CPU capacity to handle the overhead of the replication functions.
  I/O usage. The system may need more disks to provide for the additional I/Os caused by the replication function.
  Network capacity. Because the replication function occurs over a network, it may be necessary to increase the capacity of the network to compensate for the increased load.

Except for the additional overhead of the replication, treat the system as you would any other RDBMS system.

The use of Oracle replication services may or may not be a benefit to you, depending on your application and data access patterns. With Oracle replication, you may be able to think up new and innovative ways to run your business that take advantage of these features. By using replication, you may be able to distribute your business data more effectively. Which replication option you choose and how you implement it depends on your business. If at all possible, take advantage of read-only tables.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.